IBIS Macromodel Task Group Meeting date: 24 September 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 17 meeting. Randy moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: BIRD198.1: Arpad and Randy noted that no new BIRD198 updates were available. They had not yet heard back from the authors. Enabling Back-channel in Statistical Mode: Arpad noted that discussion had run out of time at the previous meeting. Walter shared his "DC_Offset and VrefDQ" presentation. - Memory contains a differential receiver. - The reference is VrefDQ, which is set by the VrefDQ register. - Input to the model is an IR and the value of DC_Offset. The model can use the value of DC_Offset to construct the step response if it needs it. There's no guarantee that DC_Offset will be close to the actual VrefDQ. - The register is set in the memory, then hardware generates the VrefDQ signal. - We could potentially have the VrefDQ register value as an input to the model. - Alternatively, the model could choose the "best" VrefDQ register setting, i.e., the register setting that results in the VrefDQ closest to the DC_Offset. - The question is, "If the model wants to modify the output value of DC_Offset, what should it return?" Randy said he needed to think about it more. He noted that the input value of DC_Offset is useful, but he still wasn't sure it was useful to return an output value. Walter said that until this question is resolved we should leave the DC_Offset BIRD tabled. Fangyi noted one earlier idea. In statistical simulation, The Rx model could return a DC value to be added to the statistical eye. He noted that this did not have to be returned via DC_Offset, it could be a separate parameter. But it would be good to have some way for the Rx to return a DC value to the EDA tool. Walter said perhaps the DC_Offset should only be an In parameter. If we want some sort of output value, we could write a different BIRD. Randy agreed that we could add that capability later with a separate BIRD if necessary. Walter took an AR to draft another version of BIRD197.5 with DC_Offset defined only as an In parameter. Walter noted the previous discussions and his presentation on developing a DDR5 DQ Write protocol. He felt that we weren't yet in a position to address that topic fully. We need more input from other DDR5 controller and memory vendors. Walter asked for comments and discussion on the proposal to enhance BCI for statistical use. Ambrish asked if this proposal was attempting to solve an existing need or anticipate a future need. Walter referred to slide 3 of his "BCI For Statistical" presentation from two weeks prior. He noted that both model makers and end users had requested this functionality. Fangyi asked if having the DDR5 DQ Write protocol defined was a prerequisite for deciding on this BIRD. Walter said that the protocol would be dependent on the BIRD. The BIRD is approved by IBIS and defines the new parameters, new AMI function, etc. It only defines the mechanisms used. The protocol specifies what information is passed between the Tx and Rx, and it's strictly between the Tx and Rx model makers. Walter noted that there had been discussions about "official" IBIS protocols, but the process for doing so had not yet been formalized. Fangyi asked if the contents of the protocol were passed in the newly proposed BCI_parameters_in and BCI_parameters_out parameters? Walter noted that BIRD147 used file I/O between the Tx and Rx models, and the BIRD had only defined the file as the communication mechanism. What the Tx and Rx put into the file was up to the specific protocol. If we used the BIRD147 type file I/O, then these proposed parameters would not be introduced. However, Walter preferred that we introduce these parameters and let the Tx and Rx communicate via parameter strings passed between them. He noted that the EDA tool still did not play any part in the protocol itself. It merely passed the strings in these parameters from one model to the other. Walter suggested names of AMI_Impulse or AMI_Get_Impulse for this new function. Walter used AMI_Impulse for the purpose of this discussion. He noted that the AMI_Impulse function took the exact same arguments as AMI_Init. Arpad asked why we would pass the same IR into AMI_Impulse if we'd already passed it into AMI_Init. Walter said we still need to pass in an IR block of data so the model can overwrite it. We need the placeholder, so let's keep it simple and the same as AMI_Init. Walter noted that he wanted to leave the existing AMI_Init flow untouched, so he wanted to add a new function instead of contemplating changes to the way AMI_Init might be called. Fangyi asked about the flow and what IR is passed in to AMI_Impulse. Walter said the call to the Tx always gets the channel IR. The Tx's output IR is then passed to the Rx AMI_Impulse function. The process iterates for perhaps several hundred times until the Tx decides it has hit upon the optimum settings. At this point, the Tx tells the Rx it has converged and gives the Rx the final tap settings. The Rx then reports to the EDA tool that training has completed, and the EDA tool uses the IR output from this final call to the Rx's AMI_Impulse function. Arpad asked if the output IR of AMI_Init would ultimately be discarded if this AMI_Impulse flow were followed. Walter said it would. Ambrish asked why this training couldn't be handled with the existing AMI_GetWave flow. Walter said the algorithms would be similar, but with the AMI_GetWave flow you're typically limited to about 10k bits per block and looking at a 1e-4 BER contour vs. 1e-16 for statistical. He noted that some vendors only do optimization in statistical and some only in time-domain. He noted that we already have BCI flow for time-domain, and this would give us a way to do it in statistical. He noted the new parameter that would specify whether BCI was supported by the model in statistical, time-domain, or both. Ambrish noted that he was trying to weigh the tradeoff in complexity of adding this new flow to the spec. He said it would make more sense if the flow converged more quickly than several hundred iterations. Walter noted that it's typical in a DDR5 example to have two FFE taps and 4 DFE taps. If you optimize over all the combinations of those 6 parameters, several hundred iterations to find the optimum solution is pretty fast. Fangyi said he had the impression that this flow was a repeated statistical simulation. The Tx could sweep through its tap settings, and at each step the Rx could optimize its settings according to the IR it received. Walter said that Rx hardware can't optimize itself, and the Tx is responsible for all of the optimization. The flow Fangyi described could work as an optimization flow, but we need to be able to model the actual hardware flow. There's an optimization algorithm in the Tx hardware, and Tx vendors want to model that optimization. Traditional sweeping and optimization techniques within EDA tools are what is done now, but the customers need to model their own optimization. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to draft a new revision of BIRD197.5 with DC_Offset defined only as an In parameter. ------------- Next meeting: 1 October 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives